Developing software applications and products often requires the coordinated efforts of many developers (e.g., software programmers). This coordinated effort is referred to herein as a “software development effort” or “development effort,” and the body of work (e.g., one or more software applications and/or products) being developed by the effort is referred to as a “software development project”, “development project” or “project”. At any given time, as part of a software development effort, multiple developers may be working on different components of a software development project and/or different versions of these components (e.g., for different users or situations). Managing the concurrent development of these different software components and versions is commonly referred to as configuration management (CM). CM software applications (i.e., programs) assist developers and project managers in the management of a software development project, including maintaining coherency between different components and versions.
A software development project typically includes a plurality of software components (e.g., files and directories). Some CM applications provide each developer a “workspace” (defined below) in which the developer can add, modify and delete components of the development project pertinent to the developer's objective. Such a workspace may provide the developer a visual presentation of the software project, referred to herein as a “view” of the project. A view can be considered a developer's window into the software project. Some CM applications are limited to always providing a developer a view of the complete set of software components included in a development project. Other CM applications enable a user to selectively view less than all of the components of the software project so that the developer can see relevant components and not be distracted by irrelevant components. For example, some known applications enable a user to specify rules indicating whether to include/exclude a specific software component in/from a particular developer's view of the project. For example, a rule may specify to “include” a file in a developer's view or to “exclude” a directory from a developer's view. Such rules are referred to herein as “include/exclude rules” or “I/E rules.”
As the number of software components of a project grows, a developer's view becomes more “crowded,” and often more time-consuming and difficult to navigate. Thus, it may be desirable for a developer to exclude certain software components from his/her view, for example, components on which the developer is not working. Limiting the number of software components provides a simpler view of the project to the developer and allows the developer to concentrate (visually and mentally) on only the software components with which he/she is concerned. Further, such a simplified view makes it easier for the developer to navigate the view.
Known CM applications that provide the ability to specify whether to include a software component in a developer's view are limited to making such a specification only for the current time. For example, such a CM application may store I/E rules and information related thereto in a simple text file. Such CM applications may allow a developer's view to be altered by editing the text file to reflect new rules or information related thereto. However, after this alteration is made, the CM application does not maintain any information regarding the parameters of the prior view, i.e., the software components that previously were included or excluded from the developer's view. In other words, known CM applications do not maintain a history of information pertaining to I/E rules. Thus, after a developer's view has been changed, there is no way to determine the developer's previous view in an automated fashion. To make such a determination, one must resort to backed-up data (e.g., tape or disk backup)—if it even exists.
Resorting to backed-up data is not only time-consuming and inconvenient, but is also limited by the frequency at which the data is backed up. For example, if data is only backed up daily, then any modifications made between backups over the course of a day are lost.
Another drawback to known CM applications is that I/E rules can only be specified on a per-developer basis. Thus, if it is desired to exclude the same software component from the respective views of several developers, a separate I/E rule must be specified for each developer's view. For example, a team of developers may be working on a portion of a project that does not require them to work on any files within a particular directory. Thus, none of the members of the team need to see the directory in his/her respective view and neither they nor their supervisor desire that they see that directory. To exclude the directory from the views of all of the team members, known CM applications require a separate I/E rule to be specified for each developer's view. It is time-consuming to create such rules and time-consuming to change them. Also, there is no simple way for a supervisor to confirm compliances.